Integration gateway

ABSTRACT

A message oriented middleware server application executable by at least one processor implements a message oriented middleware message provider that mediates messaging operations with a plurality of heterogeneous applications including a number of casino gaming applications, where instances of the heterogeneous applications which execute on the plurality of networked processor-based client devices including the networked processor-based casino gaming devices.

BACKGROUND OF THE INVENTION

1. Field of the Invention

This description generally relates to the field of communicationsnetworks, and more particularly to middleware for facilitatingcommunication in heterogeneous communications networks.

2. Description of the Related Art

Many gaming properties are attempting to integrate and leverage theinformation and capabilities provided by all of the computing deviceslocated on their property. This would provide players with a moreseamless experience, as they would have access to greater functionalityat every computing device they interact with. Moreover, the gamingproperties will also be able to better track players' activities andbetter determine what service appeal to which players.

Unfortunately, gaming properties typically include a variety ofdifferent gaming devices, gaming servers and gaming software. Often,these gaming devices, gaming servers and gaming software have beendistributed by different gaming suppliers, and may be associated withproprietary protocols developed by each of those different gamingsuppliers. Indeed, many gaming properties have legacy gaming devices andsoftware on their gaming floors that use protocols that are no longersupported. Thus, the task of interoperability and communication has beenmade much more difficult by these heterogeneous components. Althoughthere are communication standards that have been developed by groupssuch as the Gaming Standards Association, many gaming suppliers expandupon (or even ignore) these standards in order to improve thefunctionality they can offer.

It would therefore be desirable to enable improved communication betweenheterogeneous components in a gaming property.

BRIEF DESCRIPTION OF THE SEVERAL VIEWS OF THE DRAWINGS

FIG. 1 is a schematic view of a network including an integration gatewayfor enabling communications among heterogeneous components, according toone illustrated embodiment.

FIG. 2 is a schematic view of one example architecture for theintegration gateway of FIG. 1, according to one illustrated embodiment.

FIG. 3 is a process flow showing a messaging process, according to oneillustrated embodiment.

In the drawings, identical reference numbers identify similar elementsor acts. The sizes and relative positions of elements in the drawingsare not necessarily drawn to scale. For example, the shapes of variouselements and angles are not drawn to scale, and some of these elementsare arbitrarily enlarged and positioned to improve drawing legibility.Further, the particular shapes of the elements as drawn, are notintended to convey any information regarding the actual shape of theparticular elements, and have been solely selected for ease ofrecognition in the drawings.

DETAILED DESCRIPTION OF THE INVENTION

In the following description, certain specific details are set forth inorder to provide a thorough understanding of various disclosedembodiments. However, one skilled in the relevant art will recognizethat embodiments may be practiced without one or more of these specificdetails, or with other methods, components, materials, etc. In otherinstances, well-known structures associated with servers, networks,displays, and/or with computer type devices have not been shown ordescribed in detail to avoid unnecessarily obscuring descriptions of theembodiments.

Unless the context requires otherwise, throughout the specification andclaims which follow, the word “comprise” and variations thereof, suchas, “comprises” and “comprising” are to be construed in an open,inclusive sense, that is as “including, but not limited to.”

Reference throughout this specification to “one embodiment” or “anembodiment” means that a particular feature, structure or characteristicdescribed in connection with the embodiment is included in at least oneembodiment. Thus, the appearances of the phrases “in one embodiment” or“in an embodiment” in various places throughout this specification arenot necessarily all referring to the same embodiment. Furthermore, theparticular features, structures, or characteristics may be combined inany suitable manner in one or more embodiments.

As used in this specification and the appended claims, the singularforms “a,” “an,” and “the” include plural referents unless the contentclearly dictates otherwise. It should also be noted that the term “or”is generally employed in its sense including “and/or” unless the contentclearly dictates otherwise.

The headings and Abstract of the Disclosure provided herein are forconvenience only and do not interpret the scope or meaning of theembodiments.

Any process descriptions or blocks in flowcharts described below may beunderstood as representing modules, segments, or portions of code whichinclude one or more executable instructions for implementing specificlogical functions. In alternative embodiments, various logicalfunctions, or acts may be executed out of order from that shown ordiscussed, including substantially concurrently or in reverse order,and/or manually, depending on the functionality involved, as would beunderstood by those reasonably skilled in the art.

Glossary

Acknowledgement: Control messages exchanged between clients and brokerto ensure reliable delivery. There are two general types ofacknowledgement: client acknowledgements and broker acknowledgements.

Administered Objects: A pre-configured object—a connection factory or adestination—that encapsulates provider-specific implementation details,and is created by an administrator for use by one or more JMS clients.The use of administered objects allows JMS clients to beprovider-independent. Administered objects are placed in a JNDI namespace by and are accessed by JMS clients using JNDI lookups.

Asynchronous Messaging: An exchange of messages in which the sending ofa message does not depend upon the readiness of the consumer to receiveit. In other words, the sender of a message need not wait for thesending method to return before it continues with other work. If amessage consumer is busy or offline, the message is sent andsubsequently received when the consumer is ready.

Authentication: The process by which only verified users are allowed toset up a connection to a broker.

Authorization: The process by which a message service determines whethera user can access message service resources, such as connection servicesor destinations, to perform specific operations supported by the messageservice.

Broker: The Message Queue entity that may manage, inter alia, messagerouting, delivery, persistence, security, and logging, and that providesan interface for monitoring and tuning performance and resource use.

Client: An application (or software component) that interacts with otherclients using a message service to exchange messages. The client can bea producing client, a consuming client, or both.

Connection: A communication channel between a client and a broker usedto pass both payload messages and controls.

Messages Connection Factory: The administered object the client uses tocreate a connection to a broker. This can be a Connection Factoryobject, a Queue Connection Factory object or a Topic Connection Factoryobject.

Consumer: An object (Message Consumer) created by a session that is usedfor receiving messages sent from a destination. In the point-to-pointdelivery model, the consumer is a receiver or browser (Queue Receiver orQueue Browser); in the publish/subscribe delivery model, the consumer isa subscriber (Topic Subscriber).

Data store: A database where information (e.g., durable subscriptions,data about destinations, persistent messages, auditing data) needed bythe broker is permanently stored.

Delivery mode: An indicator of the reliability of messaging: whethermessages are guaranteed to be delivered and successfully consumed onceand only once (persistent delivery mode) or guaranteed to be deliveredat most once (non-persistent delivery mode).

Delivery model: The model by which messages are delivered: eitherpoint-to-point or publish/subscribe. In JMS, there are separateprogramming domains for each, using specific client runtime objects andspecific destination types (queue or topic), as well as a unifiedprogramming domain.

Destination: The physical destination in a Message Queue broker to whichproduced messages are delivered for routing and subsequent delivery toconsumers. This physical destination is identified and encapsulated byan administered object that a client uses to specify the destination forwhich it is producing messages and/or from which it is consumingmessages.

Encryption: A mechanism for protecting messages from being tampered withduring delivery over a connection.

Group: The group to which the user of a Message Queue client belongs forpurposes of authorizing access to connections, destinations, andspecific operations.

Message service: A middleware service that may provide asynchronous,reliable exchange of messages between distributed components orapplications. It may include a broker, the client runtime, the severaldata stores needed by the broker to carry out its functions, and theadministrative tools needed to configure and monitor the broker and totune performance.

Messages: Asynchronous requests, reports, or events that are consumed bymessaging clients. A message may have a header (to which additionalfields can be added) and a body. The message header specifies standardfields and optional properties. The message body contains the data thatis being transmitted.

Messaging: A system of asynchronous requests, reports, or events used byapplications that may allow loosely coupled applications to transferinformation reliably and securely.

Producer: An object (Message Producer) created by a session that is usedfor sending messages to a destination. In the point-to-point deliverymodel, a producer is a sender (Queue Sender); in the publish/subscribedelivery model, a producer is a publisher (Topic Publisher).

Queue: An object created by an administrator to implement thepoint-to-point delivery model. A queue is available to hold messageseven when the client that consumes its messages is inactive. A queue maybe used as an intermediary holding place between producers andconsumers.

Selector: A message header property used to sort and route messages. Amessage service may perform message filtering and routing based oncriteria placed in message selectors.

Session: A single threaded context for sending and receiving messages.This can be a queue session or a topic session.

Topic: An object created by an administrator to implement thepublish/subscribe delivery model. A topic may be viewed as a node in acontent hierarchy that is responsible for gathering and distributingmessages addressed to it. By using a topic as an intermediary, messagepublishers may be kept separate from message subscribers.

Transaction: An atomic unit of work that must either be completed orentirely rolled back.

Integration Gateway—Middleware

FIG. 1 illustrates a network 10 including an integration gateway module12 for enabling communications among a number of heterogeneouscomponents. In one embodiment, the network 10 may comprise a gamingnetwork located within at least partially within a gaming property.However, in other embodiments, the network 10 may comprise any of avariety of intranets, extranets, or other networks.

As illustrated, the heterogeneous components within the network 10include applications 14, 16, other software components 18, and a numberof servers 20 a, b, c (collectively 20). The applications 14, 16 andother software components 18 may communicate with the integrationgateway 12 via an application programming interface 22 (“API”), whilethe servers 20 communicate via their respective server interfaces 24 a,b, c (collectively 24). In one embodiment, the servers 20 may comprise aplurality of different platforms and may communicate via theirrespective platform interfaces.

As illustrated, the integration gateway module 12 may be accessible viaa computing system 26. As would be well understood by those skilled inthe art, the computing system 26 may comprise any of a variety ofcomputers/servers. In one embodiment, the computing system 26 may enableadministration and configuration of the integration gateway 12.

The integration gateway 12 allows the components of the network 10 tocommunicate despite their differences. Thus, these heterogeneouscomponents do not need to be recreated as homogeneous elements. Theintegration gateway 12, sometimes referred to as “middleware,” mayenable the software components (e.g., applications, enterprise javabeans, servlets, and other components) that have been developedindependently and that run on different networked platforms to interactwith one another. In some embodiments, the integration gateway 12resides between the application layer and the platform layer (i.e., theoperating system and underlying network services).

Applications distributed on different network nodes (e.g., applicationsexecuting on the servers 20) may use the integration gateway 12 tocommunicate without having to be concerned neither with the details ofthe operating environments that host other applications nor with theservices that connect them to these applications. In addition, anadministrative interface may be provided on the computing system 26.This administrative interface may enable personnel working on thenetwork 10 to keep this virtual system of interconnected applicationsreliable and secure. The performance of the network 10 can also bemeasured and tuned, and the network 10 may even be scaled without losingfunction.

In one embodiment, the integration gateway 12 may serve as a singleimplementation/communication point to communicate with variousenterprise products. Each of these various enterprise products (e.g.,each of the servers 20) may use industry-specific protocols, like theSystem to System (S2S) Protocol promulgated by the Gaming StandardAssociation, in order to communicate with the integration gateway 12.Indeed, a variety of different protocols, including proprietary andstandard protocols, may be used to communicate via the integrationgateway 12. The integration gateway 12 may also facilitate real-timeinformation access among disparate systems within the network 10,thereby helping to streamline business processes and improveorganizational efficiency.

Middleware can be generally grouped into the following categories, whichmay each be supported by or integrated into the integration gateway 12:

Remote Procedure Call or RPC-based middleware: Such middleware may allowprocedures in one application to call procedures in remote applicationsas if they were local calls. The middleware can implement a linkingmechanism that locates remote procedures and makes these transparentlyavailable to a caller. This type of middleware may be handled byprocedure-based or object-based programs or components.

Object Request Broker or ORB-based middleware: Such middleware mayenable an application's objects to be distributed and shared acrossheterogeneous networks.

Message Oriented Middleware or MOM-based middleware: Such middleware mayallow distributed applications to communicate and exchange data bysending and receiving messages.

Each of these categories makes it possible for one software component toaffect the behavior of another component over the network 10. They aredifferent in that RPC- and ORB-based middleware may create systems oftightly-coupled components, whereas MOM-based systems may allow for alooser coupling of components. In an RPC- or ORB-based system, when oneprocedure calls another, the procedure may wait for the called procedureto return before it can do anything else. As mentioned before, in eachof these categories, the middleware (i.e., the integration gateway 12,in one embodiment) functions partly as a super-linker, locating thecalled procedure on the network 10 and using network services to passfunction or method parameters to the procedure and then to returnresults.

Message Oriented Middleware

In general, MOM-based systems may make use of a messaging provider tomediate messaging operations. The basic elements of a MOM-based systemare Clients, messages, and the MOM messaging provider, which may includean API and administrative tools. The MOM provider may use a variety ofdifferent architectures to route and deliver messages: it can use acentralized message server, or it can distribute routing and deliveryfunctions to each Client machine. Some MOM-based systems combine thesetwo approaches.

Using a MOM-based system, in one embodiment, a Client makes an API callto send a message to a destination managed by the MOM provider. The callinvokes provider services to route and deliver the message. Once it hassent the message, the Client can continue to do other work, while theMOM provider retains the message until a receiving Client retrieves it.The message-based model, coupled with the mediation of the MOM provider,makes it possible to create a system of loosely-coupled components. TheMOM-based system may therefore be able to continue to function reliably,without downtime, even when individual components or connections fail.

The MOM provider may also include an administrative interface, usingwhich an administrator can monitor and tune performance. Clientapplications are thus effectively relieved of messaging-related tasksexcept those of sending, receiving, and processing messages. TheMOM-based system and the administrator can work to resolve issues likeinteroperability, reliability, security, scalability, and performance,without modifying the client applications.

Integration Gateway Overview

The integration gateway 12 may comprise a Java-based MOM solution thatallows client applications to create, send, receive, and read messagesin a distributed enterprise system, such as network 10. Of course, inother embodiments, the integration gateway 12 may be written in otherprogramming languages, and may run on a variety of platforms. Theintegration gateway 12 may reduce the complexity of embedding diversecommunication protocols within the client applications, making it fasterand easier to integrate third-party host/legacy applications with newerproducts. The integration gateway 12 may also improve the reliability,flexibility and scalability of messaging. The heterogeneous nature ofthe network 10 may arise from both the technology on which the productsin the network 10 are based and/or the protocols that they support tocommunicate with the other systems.

The integration gateway 12 can play a variety of roles within thenetwork 10: it may comprise a stand-alone product or may be used as anembedded component in a larger distributed runtime system. As astandalone product, the integration gateway 12 may define the backboneof an enterprise application integration system. Embedded in anapplication server, the integration gateway 12 may supportinter-component messaging. For example, J2EE uses a JMS provider toimplement message-driven beans and to allow EJB components to send andreceive messages. In one embodiment, message mapping/conversionaccording to the destination requirements may be implemented as apluggable component. This may enable various channels and products toexchange messages without being concerned about potentialincompatibilities.

The integration gateway 12 may provide a number of features/advantageswithin the network 10: the integration gateway 12 may be flexible,scalable, reliable, and may provide synchronous and asynchronousmessaging across various platforms; the integration gateway 12 mayprovide fast, guaranteed message delivery, receipt notification,transaction control and a data persistence mechanism for multipleproducts and platforms; the integration gateway 12 may eliminatecomplexity of embedding communication protocols in business logic; theintegration gateway 12 may provide support for cross-platform Clientsand servers; the integration gateway 12 may support platform dependentcommunication protocols, data formats and encoding; the integrationgateway 12 may also support for the following messaging models:Publish-Subscribe Messaging, Point-to-Point Messaging, and/orRequest-Reply Messaging; the integration gateway 12 may also provide astand-alone GUI for setup and maintenance, and may support commonmessage formats such as stream, text, and byte.

In one embodiment, the integration gateway 12 may provide a flexible MOMsolution, which may be easily customized according to the needs ofinternal products which differ in technology and in the interfaces usedfor communication. In another embodiment, the integration gateway 12 mayallow legacy systems to communicate (e.g., indirectly via theintegration gateway 12) with newer products based on evolvingtechnologies.

Integration Gateway Architecture

FIG. 2 shows one example architecture for the integration gateway 12. Asillustrated, the integration gateway 12 may include the following: LocalConfiguration Cache Services 200, a Common Services Layer 202, a DataTransformation Layer 204, a Messaging Layer 206, a CommunicationServices Layer 208, and an Interceptor Services Layer 210.

Each of these services comprising the integration gateway 12 is detailedin greater detail in the following sections.

Local Configuration Cache Services

The local configuration cache services 200 represent the servicesconfiguration folder structure in the integration gateway 12. Thisservices configuration folder structure may be created during theinstallation process of the integration gateway 12 and may be used tomanage the configurations for each service provided by the integrationgateway 12. In one embodiment, the integration gateway 12 does notinclude a database. Although, in other embodiments, of course, theintegration gateway 12 may include one or more databases.

Common Services Layer

The common services layer 202 acts as a common services layer. That is,the common services layer 202 may represent (and provide access to) thecommon functions used by the integration gateway 12, such as, logging,configuration, database access and other foundation classes.

Data Transformation Layer

The data transformation layer 204 may include code that forms the outletfor custom or platform-specific data manipulation and formatting. Thislayer 204 may be used for data in both inbound and outbound messageQueues. The business logic execution may be based on the message typesused. (Example: Responding with an ACK message in the S2S protocol forincoming messages.)

In one embodiment, the data transformation layer 204 supports thefollowing data types: Simple Strings, XML (Complex), Files, Images &Bitmaps (Byte Streams), and Serializable Objects (Marshal By Value). Inother embodiments, of course, other data types may be supported.

The data transformation layer 204 may also support the following dataencoding options: ASCII, EBCDIC, and UTF-8. Again, in other embodiments,other data encoding options may be supported.

Messaging Layer

In one embodiment, the messaging layer 206 acts as a central layer forthe integration gateway 12, and enables the management of messages andobjects for inter-application communication. The messaging layer 206 maybe designed based on Publisher/Subscriber or Point-to-Point(Asynchronous) messaging models utilizing JMS Topics (Producer/ConsumerObject classes). The messaging layer 206 may also use theRequest/Response (Synchronous) model using JMS Queues.

In one embodiment, the messaging layer 206 may enable messagepersistence using Durable Topics/Queues, and may enable theadministration of integration gateway services using a stand-alone userinterface. The messaging layer 206 may also enable configuration ofcertain services (e.g., Publisher/Subscriber and Point-to-Point) usingthe stand-alone user interface. Finally, the messaging layer 206 mayinclude failover and load-balancing, which may be implemented using SunJava System Message Queue 4 2005Q1 Enterprise Edition.

Messaging Domains

Generally, the integration gateway 12 (and, in particular, the messaginglayer 206) may allow components and applications to communicate byproducing and consuming messages. The integration gateway 12 defines twopatterns or messaging domains that govern this communication. Thesemessaging domains are Point-to-Point Messaging and Publish/SubscribeMessaging (as described above). The integration gateway 12 may beconfigured to support either or both of these patterns. The basicintegration gateway objects include connections, sessions, Producers,Consumers, destinations, and messages that are used to specify messagingbehavior in both domains.

Point-to-Point Messaging

In the Point-to-Point domain, message Producers are called Senders andConsumers are called Receivers. The senders and receivers may exchangemessages by means of a destination called a Queue: senders producemessages to the Queue, and receivers consume messages from the Queue.

Point-to-Point messaging may provide a number of features. First, morethan one Producer may be allowed to send messages to a Queue. SuchProducers can share a connection or use different connections, eventhough they may all access the same Queue. Second, more than oneReceiver may be allowed to consume messages from a Queue. However, inone embodiment, each message can only be consumed by one Receiver. ThusMsg1, Msg2, and Msg3 will be consumed by different Receivers. Third,Receivers can share a connection or use different connections, but theymay all access the same Queue. Fourth, the sending and receiving ofmessages via Point-to-Point messaging may be enabled with no timingdependencies. Thus, a Receiver can fetch a message even if it wasrunning when the Client sent the message. Fifth, Senders and Receiversmay be added and deleted dynamically at runtime. This feature may allowthe integration gateway 12 to expand or contract as needed. Sixth,messages may be placed on the Queue in the order sent, but the order inwhich they are consumed may depend on factors such as message expirationdate, message priority, and whether a selector is used in consumingmessages.

The Point-to-Point domain may also offer certain advantages. Forexample, the fact that multiple Receivers can consume messages from thesame Queue may allow effective load-balancing of message consumption, aslong as the order in which messages are received is not important. Asanother example, messages destined for a Queue may be retained, even ifthere are no Receivers. Finally, Clients may be able to use a Queuebrowser object to inspect the contents of a Queue. The Clients can thenconsume messages based on the information gained from this inspection.That is, although the consumption model is normally FIFO (first in,first out), in some embodiments, Clients can consume messages that arenot at the head of the Queue if they know what messages they want basedat least in part on message selectors. Administrative Clients may alsouse the Queue browser to monitor the contents of a Queue.

Publish/Subscribe Messaging

In the Publish/Subscribe domain, message Producers are calledPublishers, and message Consumers are called subscribers. The Publishersand Subscribers may exchange messages by means of a destination called atopic: Publishers produce messages to a topic, and Subscribers subscribeto a topic and consume messages from a topic.

The subscribers to these topics can be non-durable or durable. TheBroker may be configured to retain messages for all active subscribers,but it may be configured to only retain messages for inactivesubscribers if these subscribers are durable.

In the Publish/Subscribe domain, more than one Producer may be allowedto publish messages to a topic. Such Producers can share a connection oruse different connections, but they may all access the same topic. Insome embodiments, more than one subscriber can consume messages from atopic. The subscribers may retrieve all of the messages published to atopic unless they use selectors to filter out messages or the messagesexpire before they are consumed. Subscribers can also share a connectionor use different connections, but they may all access the same topic. Asdescribed above, durable subscribers can be active or inactive. However,even when a durable subscriber is inactive, the Broker may be configuredto retain messages for them. Publishers and subscribers may be added anddeleted dynamically at runtime, thus allowing the integration gateway 12to expand or contract as needed. In one embodiment, messages arepublished to a topic in the order sent, but the order in which they areconsumed depends on factors such as message expiration date, messagepriority, and whether a selector is used in consuming messages.Publication and subscription may include a timing dependency. Forexample, a topic subscriber may be able to consume only those messagespublished after it has created the subscription.

In some embodiments, the Publish/Subscribe domain may allow message tobe broadcast to subscribers.

A session object may be used to create a Durable Subscriber to a topic.The Broker may then retain messages for such subscribers even when thesubscriber becomes inactive.

In some embodiments, because the Broker must maintain the state for thesubscriber and resume delivery of messages when the subscriber isreactivated, the Broker can identify a given subscriber during itscomings and goings. The subscriber's identity may be constructed from aClient ID, a property of the connection that created the subscriber, anda subscriber name specified at the time of its creation. Other means ofidentifying the subscriber may be used in different embodiments.

Communication Services Layer

The Communication Services Layer 208 may serve as the primary layerresponsible for inter-system communication. Message integrity may beachieved with ACK/NAK messaging architecture, while the Keepalivesupports a real-time Request/Response message protocol.

The Web services provided by the Communication Services Layer 208 mayenable communication among different products produced by differentcompanies.

For example, communication between a Third Party Debit Ticket Kiosksystem and ACSC for the Ticket number sequence may be enabled. In suchan embodiment, the Debit Ticket Kiosk may send out messages using theS2S protocol to the integration gateway 12, and the integration gateway12 can then communicate with ASCS, obtain a response and form anS2SMessage to send back to Debit Ticket Kiosk.

The Web Services may use message processor plug-ins to translatemessages into the format required by the requested system.

In one embodiment, the communication services layer 208 may support thefollowing protocols: Basic low-level Client/Server TCP/IP sockets,Secure File Transfer Protocol (SFTP), HTTP/HTTPS, SOAP (e.g. usingApache Axis2), .NET Remoting using IIOP ORB protocol, RMI (EJB), andDatabase Stored Procedures. Of course, in other embodiments, additionalprotocols, including proprietary protocols, may be supported by thecommunication services layer 208.

Interceptor Services Layer

The Interceptor Services Layer 210 may serve as a lightweight middlewareobject in the integration gateway 12 that coexists with applicationsand/or systems (e.g., applications and systems distributed by BallyGaming) utilizing the integration gateway services. This layer 210 maycommunicate with the local application using simple Java programs, RMI,IIOP and/or database stored procedures.

Programming Objects

In one embodiment, the objects used to implement messaging by theintegration gateway 12 may remain essentially the same acrossprogramming domains. These objects may include—Connection Factories,Connections, Sessions, Producers, Consumers, Messages, and Destinations.Table 1, below, summarizes exemplary steps for sending and receivingmessages. Note that steps 1 through 6 are the same for senders andreceivers.

TABLE 1 Producing a Message Consuming a Message 1. The administratorcreates a connection factory administered object. 2. The administratorcreates a physical destination and the administered object that refersto it. 3. The client obtains a connection factory object through a JNDIlookup. 4. The client obtains a destination object through a JNDIlookup. 5. The client creates a connection and sets any properties thatare specific to this connection. 6. The client creates a session andsets the properties that govern messaging reliability. 7. The clientcreates a message The client creates a message Producer. Consumer. 8.The client creates a message. The client starts the connection. 9. Theclient sends a message. The client receives a message.

The following sections describe objects that may be used by Producersand Consumers, such as the Connections, Sessions, Messages, andDestinations. A description of the production and consumption ofmessages follows.

Connection Factories and Connections

In one embodiment, a Client uses an object (e.g., a Connection Factory)to create a connection. The connection object (i.e., Connection)represents a Client's active connection to the Broker. It may use anunderlying connection service that is either started by default orexplicitly started by the administrator for this Client.

The allocation of communication resources and authentication of theClient may take place when a connection is created. The Connection maycomprise a relatively heavyweight object, and Clients may do all theirmessaging with just a single connection. In some embodiments,Connections support concurrent use, i.e., any number of Producers andConsumers can share a connection.

When a connection factory is created, the behavior of all connectionsderived from it may be configured by setting the properties of theconnection factory. For example, for a Message Queue, the followinginformation may be specified: the name of the host on which the Brokerresides, the connection service desired, and the port through which theClient can access the service; how to handle automatic reconnection tothe Broker if a connection fails (This feature may reconnect the Clientto the same Broker (or to a different Broker) if a connection is lost.Data failover may not be guaranteed as persistent messages and otherstate information may be lost when reconnecting to a different Broker.);the ID of Clients that need the Broker to track durable subscriptions;the default name and the password of a user attempting the connection(This information may be used to authenticate the user and to authorizeoperations if a password is not specified at connection time.); whetherBroker acknowledgements should be suppressed for those Clients who arenot concerned with reliability; how to manage the flow of control andpayload messages between the Broker and the Client runtime; and whethercertain message header fields should be overridden.

Sessions

If a connection represents a communication channel between a Client anda Broker, a session may designate a single conversation between theClient and Broker. The session object may be used to create messages,message Producers, and message Consumers. When a session is created,reliable delivery may be enabled through a number of differentacknowledgement options or through transactions.

A session may comprise a single-threaded context for producing andconsuming messages. Multiple message Producers and message Consumers maybe created for a single session, but a restriction may be instituted touse these message Producers and message Consumers serially. A sessionobject may also be used to do the following: create and configuredestinations for those Clients that do not use administered objects todefine destinations; create and configure temporary topics and Queues(These topics and Queues may be used as part of the request-replypattern (discussed in greater detail below).); support transactionprocessing; define a serial order for producing or consuming messages;and/or serialize the execution of message listeners for asynchronousConsumers.

Messages

In one embodiment, each message is composed of three parts: a header,the header's properties, and a body.

The message header may be a requirement for every valid message. Theheader may, inter alia, contain the following exemplary fields, setforth in Table 2.

TABLE 2 Header Field Description Destination Specifies the name of thedestination object to which the message is sent. (Set by the provider.)Expiration Specifies the time when the message will expire. (Set bydefault by the provider or by the client for a Producer or for anindividual message.) Priority Specifies the priority of the messagewithin a range (e.g., 0-low to 9-high). (Set by default by the provideror set explicitly by the client for a Producer or for an individualmessage.) Timestamp Specifies the time when the provider received themessage. (Set by the provider.) Type A value that can be evaluated by amessage selector. (Set by the client if needed.)

Another field that may be used is a Delivery Mode field, which maydetermine the reliability of message delivery. This field may indicatewhether a given message is persistent.

The message body contains the data that Clients want to exchange. Thetype of message may determine the contents of the message body as wellas how the message body should be processed by the consumer. Someexemplary types are set forth in Table 3. The Session object may includea create method for each type of message body.

TABLE 3 Type Description Stream Message A message with a stream ofprimitive values in its body. It is filled and read sequentially. MapMessage A message with a set of name-value pairs in its body. The orderof the entries is not defined. Text Message A message with a string inits body, such as an XML message. Object Message A message with aserialized Java object in its body. Bytes Message A message with astream of uninterrupted bytes in its body. Message A message thatcontains a header and properties but no body.

Java Clients may be configured to set a property so that the Clientruntime compresses the body of a message being sent. The Message Queueruntime on the consumer side may then decompress the message beforedelivering it.

Producing a Message

In one embodiment, messages may be sent or published by a messageProducer, within the context of a connection and/or session. In oneembodiment, a Client uses a message Producer object (Message Producer)to send messages to a physical destination, represented in the API as adestination object.

When a Message Producer is created, a default destination may bespecified to which all the Message Producer's messages will be sent bydefault. Default values for the message header fields that governpersistence, priority, and time-to-live may also be specified. Thesedefault values may then be used by all messages issued from thatProducer unless they are over-ridden. In one embodiment, these defaultvalues may be easily over-ridden, if, for example, an alternatedestination is specified when sending a message, or if alternate valuesfor the header fields are entered for a message.

Consuming a Message

The messages produced above may be received by a message consumer,within the context of a connection and/or session. In one embodiment,the client uses a message consumer object (Message Consumer) to receivemessages from a specified physical destination, represented in the APIas a destination object.

In one embodiment, three factors may affect how the Broker deliversmessages to a consumer: (1) whether consumption is synchronous orasynchronous; (2) whether a selector is used to filter incomingmessages; and (3) if messages are consumed from a topic destination,whether the subscriber is durable.

Another factor that may affect message delivery and client design is thedegree of reliability needed for the consumer.

Exemplary Messaging Process Flow

Referring to FIG. 3, one exemplary messaging process is illustrated. Asillustrated therein, client A 300 a and client B 300 b are messageProducers, sending messages 302 a, b, c (collectively 302) to client C304 c, client D 304 d, client E 304 e, and client F 304 f by way of twodifferent kinds of destinations.

Messaging between clients A, C, and D 300 a, 304 c, 304 d illustrates aPoint-to-Point pattern. Using this pattern, client A 300 a may send amessage Msg1 302 a or Msg 2 302 b to a Queue destination 306 from whichonly one of the Receivers 304 c, 304 d may get it. In the illustratedembodiment, each message may be received by only one receiver, and noother receiver accessing the Queue destination 306 can get that message.

Messaging between clients B, E, and F 300 b, 304 e, 304 f illustrates aPublish/Subscribe pattern. Using this broadcast pattern, client B 300 bmay send a message Msg3 302 c to a Topic destination 308 from which bothconsuming subscribers 304 e, 304 f can retrieve it. Each subscriber 304e, 304 f may obtain its own copy of the message 302 c.

Asynchronous/Synchronous Communication

Message Consumers in either the Point-to-Point or Publish/Subscribedomains may choose to get messages synchronously or asynchronously.Synchronous Consumers may be required to make an explicit call toretrieve a message, while asynchronous Consumers may specify a callbackmethod that is invoked to pass a pending message. In some embodiments,consumers can also filter out messages by specifying selection criteriafor incoming messages.

Asynchronous communication can be defined as communication where oneparty simply sends a message to another. Problems may arise when thesending party expects a response to the message, or when the timeframeduring which a sending entity can remember that it sent a message andthat it expects a reply is short.

Synchronous communication can be defined as communication where oneparty has a conversation with another. This may be presented as arequest-response scenario. An interface may be defined between twoObjects or Services where an invocation results in a response once therequested processing has been completed. Indeed, in some embodiments,even if there is no actual response, a void response may be required.

Services

In one embodiment, the integration gateway 12 provides support for thefollowing protocol definitions, discussed in greater detail below:Database Interface; DotNet Client; DotNet Server; FTP Get; FTP Put; HTTPGet; HTTP Post; iSeries Data Queue Writer; iSeries Data Queue Reader;Object Serializer; Object Deserializer; RMI Client DotNet Server; RMIServer DotNet Client; Socket Server; Socket Multiplexer; Socket RelayClient; Socket Client; S2S Message Client; S2S Message Service; S2SVoucher End of Day Report Service. These services and related protocolsmay facilitate intersystem communication and message processing.

Database Interface

This protocol may be used to create a service that communicates with adatabase by making a stored procedure call. The service can takeconfigurable parameters for connecting and executing a stored procedureon a database. It can then pass an entry to the host in alphanumericform and then get a response too in alphanumeric form.

Apart from the database connection parameters, the following parametersmay also be configurable: Source Event (the point on the Queue where theservice listens for incoming messages); and Destination Event (the pointon the Queue where the stored procedure reply is written).

In one embodiment, the service created listens to an event on a Queueassociated with the integration gateway 12. When a message arrives inthe Queue, if configured, the service may then process the message andpass it on to the stored procedure. If the stored procedure returns aresponse, the response is then written back to the Queue at an eventconfigured as its destination.

All database connection parameters, such as Source Event and DestinationEvent, may be configurable on a user interface of the integrationgateway 12 while creating a Database Interface service.

DotNet Client and Server

In one embodiment, the DotNet protocols may use IOP (Internet Inter-ORBProtocol) to communicate with a .NET Remoting server and/or a .NETRemoting Client. .NET Remoting is a feature of Microsoft's DotNet thatprovides RPC/RMI-like capabilities.

IOP is a protocol that enables distributed programs written in differentprogramming languages to communicate over the Internet. IOP forms a partof the industry standard, Common Object Request Broker Architecture(CORBA).

In one embodiment, the DotNet Client service listens to a Queueassociated with the integration gateway 12. When a message arrives, theservice may access a remote object on a DotNet system (e.g., a .NETRemoting Server) by passing that message as a parameter to the method onthat object. In some embodiments, the following parameters may beconfigured for the DotNet Client service: Context Provider URL (thefactory for ORB API), and Object URI (the URI of the object exposed onthe .NET Remoting Server).

The DotNet Server service may allow a DotNet system (e.g., a .NETRemoting Client) to access an object exposed via the integration gateway12, by passing a message as a parameter to the method on this object.The DotNet Server service may then write to a Queue associated with theintegration gateway 12 on the configured event. In some embodiments, thefollowing parameters may be configured for the DotNet Server service:Context Provider URL (the factory for ORB API), and Object URI (the URIof the object exposed on the integration gateway Server).

FTP Get & Put

The FTP Get Service may be used to poll a remote directory periodicallyusing the File Transmission Protocol (FTP). Once any new and relevantfile is found, the service can then download the file and write the fileobject to a Queue associated with the integration gateway 12. The Queuemay be monitored by other programs (e.g., by FTP Put), which mayretrieve the file object from the Queue.

The FTP Put Service may be used to listen to Message Events of theQueue. Once a message is written to the Queue, the service may checkwhether it is a file object. If so, the FTP Put service may retrieve andupload the file to an FTP Server.

HTTP Get & Post

The HTTP Post service may send the data of a file in a local file systemto a configured http server. The HTTP Post request can also sendadditional data to the host server, which may be specified after theURL, the headers, and a blank line to indicate the end of the headers.

The HTTP Get service may be used to download files from the configuredhttp Server to the local file system.

In some embodiments, these HTTP services may also provide otherprocessing options, e.g., by marking the downloaded/uploaded files bydeleting or renaming the files.

iSeries Data Queue Reader/iSeries Data Queue Writer

These services may be included to allow writes/reads to/from iSeriesData Queues. The iSeries Data Queue Reader service may be configured toread messages from an iSeries Data Queue and write them to the Queueassociated with the integration gateway 12. The iSeries Data QueueWriter service may be configured to listen to the Queue associated withthe integration gateway 12, and, when a message is received, write thatmessage to an iSeries Data Queue.

In some embodiments, a variety of iSeries Data Queue access parametersmay be configured on a user interface of the integration gateway 12. Forexample, the iSeries Data Queue service may be configured for thefollowing: iSeriesDataQueueRx, and iSeriesDataQueueTx.

RMI Server DotNet Client & RMI Client DotNet Server

These RMI-related protocols may enable a Java system and a DotNet systemto communicate using RPC based on IOP. The difference between the RMIServer/Client DotNet protocols and other DotNet protocols describedherein is that these RMI protocols may be designed so as not to includea Queue concept. Thus, these RMI Server/Client DotNet protocols may beused for synchronous, inter-system communication.

Object Serializer/Deserializer

Object Serialization is the process of saving an object's state to asequence of bytes, and may also be used to describe the process ofrebuilding those bytes into a live object at a later point in time. Inthe integration gateway 12, the Object Serializer service may allow allof the files in a selected directory (e.g., a source directory) to getserialized and may then write the object form of these files to theQueue associated with the integration gateway 12.

The Object Deserializer service that resides on the Queue may listen forObject messages and may deserialize them into files in a configuredpath.

Socket-Based Services

Sockets are interfaces that can “plug into” each other over a network,such as network 10. Once “plugged in”, the programs or softwarecomponents so connected can communicate with each other. A socketrepresents a single connection between exactly two pieces of software.When more than two pieces of software communicate in client/server ordistributed systems (for example, many web browsers simultaneouslycommunicating with a single web server), multiple sockets may berequired. Socket-based software may execute on two separate computers onthe network 10; however, sockets can also be used to communicate locally(i.e., inter-process) on a single computer. Various socket-basedservices may be made available on the network 10 via the integrationgateway 10.

Sockets may be bi-directional, i.e., either side of the connection iscapable of sending and receiving data. The application that initiatescommunication may be termed the client, and the other application may betermed the server.

TCP/UDP

There are two types of Internet Protocol (IP) traffic, describedgenerally in Table 4. These two types of traffic may have very differentuses.

TABLE 4 Transmission Control Protocol (TCP) User Datagram Protocol (UDP)TCP is a connection-oriented protocol, a A simpler message-basedconnectionless connection can be made from client to protocol. With UDP,you send messages server, and from then on, any data can be (packets)across the network in chunks. sent along that connection. Reliable -When a message is sent along Unreliable - Message receipts are not a TCPsocket, the message will reach its guaranteed. The messages may or maydestination unless the connection fails not be transmitted. completely.If so, the server will send a request for the lost portions of the fileagain. Ordered - Messages are sent and listed in Not ordered - Messagessent may not be the order in which they are sent. listed in the order inwhich they are sent. Heavyweight - When the low-level parts ofLightweight - There is no ordering of the TCP “stream” arrive in thewrong messages, no tracking connections, etc. It order, requests must bere-sent, and all of is often quicker, and the network card/ the out ofsequence parts must be put operating system have little work to do inback together before sending them. translating data back from thepackets.

For socket-based protocols, the integration gateway 12 may allowconfiguration of the type of the protocol, i.e., whether it is TCP orUDP.

Socket Server

Once a socket server service is started, a server socket may wait at theconfigured port for requests to come in over the network 10. The socketserver may then perform operations based on those requests, and thenpossibly return results to the requester.

In some embodiments, this protocol enables different socket behaviorsbased on two configuration parameters: the parameter ‘Listener’, and theparameter ‘Full Duplex’. The parameter ‘Listener’ is a Boolean parameterand may cause the socket to act as a server. If set to true, the socketwaits for requests, and accepts connections. If set to false, the socketmay connect to an external server socket on the network 10.

The parameter ‘Full Duplex’ is a Boolean parameter related to two-waycommunication on the same line. When set to true, the socket may behavein a two-way fashion. When the Full Duplex parameter is configured totrue, a ‘Full Duplex Event’ value may also be configured in order toidentify the point where the service listens to the Queue of theintegration gateway 12 for incoming messages. This value may be writtento the socket. If the Full Duplex parameter is set to false, thecommunication is one way. That is, the socket listens at a port andwrites the incoming message to the Queue associated with the integrationgateway 12 at the specified point configured in ‘Request Event’.

The Full Duplex parameter may be used to define the type ofcommunication between the Queue and the Socket Server Service. However,irrespective of the Full Duplex value, a socket may be configured tosend or receive data.

Socket Multiplexer

For the socket multiplexer service, the integration gateway 12 mayenable configuration of the following parameters: port number IP (IPaddress where the server socket will be opened); multiplexer ports (alist of values, each value in the format of ‘IPaddress: Port’; theassumption being that server sockets are listening at all of these portsat the corresponding IP address); and single pipe (when set to true, theconversation ends with a single request/response scenario, the Clientsocket is closed, and looped for the next Client connection).

The socket multiplexer service may be configured to open a server socketat the specified IP address and port and listen for incomingconnections. When a Client connects, the incoming messages may be routedto a list of server sockets (configured by the parameter ‘multiplexerports’) sequentially. The first message to the first socket, the secondmessage to the second socket, and so on.

In some embodiments, this service will help with load balancing in ahigh message traffic scenario.

Socket Relay Client

The socket relay client service may constitute two threads: Receiver andTransmitter. These two threads may enable two-way communication betweena server socket and a regular socket. Each of these threads may beconfigured to read from one socket and write to another socket, whichmay help in controlling traffic between the two sockets.

Socket Client

Socket client services may listen to the Queue of the integrationgateway 12. When a message is received, the socket client service writesto the configured IP address and port number. In some embodiments, a‘Listener’ value can be configured to obtain Server Socket attributes.The period of delay in sending the acknowledgment after sending themessage may also be configured using the parameter ‘ackWait’. If anacknowledgement is not received within the scheduled time, the messagemay be re-sent.

All of the socket services discussed above may also include other valuesthat can be configured, such as: Start of Message (SOM); End of Message(EOM); and/or Acknowledgment Message (ACK).

S2S Protocol

The System to System (S2S) Messaging standard set by the Gaming StandardAssociation provides a set of communication protocols between gaminghost systems (e.g., accounting, security, progressive controllers,advertising, and promotion displays), as well as between gaming andnon-gaming host systems. This S2S standard has emerged as ahospitality-gaming industry solution. The current version of the S2Sstandard includes support for the following types of gaming andnon-gaming communications: patron registration; player ratings (e.g.,with respect to table games, slots, bingo, keno, poker, sports book);table games accounting (hourly estimates, open and closing, fills andcredits, marker and chip purchase vouchers support); comps (e.g.,complimentary awards, points, money, or hospitality products); system,data and device configurations (such as defining active/inactive gametypes and calculations, progressive controllers, chip sets, regionalsettings, shifts, or codes for particular types of data, such as club orbadge identifiers).

S2S Message Service

The S2S Message Service on the integration gateway 12 may comprise a webservice that is exposed to Clients who want to communicate using the S2Sprotocol. Both synchronous and asynchronous versions of S2S may besupported. An interceptor value may be configured based on thesynchronous or asynchronous nature required. An interceptor may functionas an entry point to the integration gateway 12 for the incomingmessages over the network 10, and it may also handle the messageprocessing tasks required for requests and responses. This messageprocessing may even include translations performed for messagesaccording to the target system requirements. In one embodiment, thefollowing interceptors may be supported:

Asynchronous Interceptor: This interceptor may write incoming messagesto a socket, which in turn writes the message to the Queue of theintegration gateway 12. This interceptor may be configured to achieveasynchronous S2S attributes.

Database Interceptor: This interceptor may make a stored procedure callusing the configured database connection parameters and return aresponse.

Java Interceptor: This interceptor may make a Java RMI call to a remotemethod for which the message is sent as a parameter, in order to receivea response.

DotNet Interceptor: This interceptor may access an exposed object on a.Net Remoting server to access a remote method by passing the message asa parameter.

iSeries Interceptor: This interceptor may make a call to a serviceprogram written on iSeries.

S2S Message Client

The S2S message client service may be configured to listen to the Queuefor S2S responses and then write these S2S responses to a Web ServiceClient. The target URL may be configured as a parameter in someembodiments.

S2S End of the Day Voucher Report Service

For Debit Ticket Kiosk functionality, a Client may generate a requestfor a report that lists the ticket details for tickets issued during thecurrent day. A corresponding S2S message may contain login details tothe remote host and the required report name. The integration gateway 12can then perform S2S translations to generate a flat string message forACSC.

ACSC may then respond with the link of the server to the integrationgateway 12, which, in turn, may use FTP to download the report from theidentified server. The downloaded report may then be translated to S2Sformat and returned to the Client.

Service Settings on GUI

The integration gateway 12 may allow the creation of multiple groups andservices based on the application and requirements. In one embodiment,the groups may be logically named. Groups and services may also becreated within the groups. In one embodiment, the same service may existmultiple times in the same group; however, it may have to be renamed.The following actions can be performed for each service: Start Service(used to start a selected service); Stop Service (used to stop aselected service); Configure Service; Save Service (used to save aservice selected after the configuration); and Delete Service (used toremove a selected service).

The services may be configured in a variety of ways, depending on theIdentity, Message, Filter and Client within a group. These settings maybe common to all of the different service/protocol settings.

Identity On The GUI

In one embodiment, an Identity tab displayed in the graphical userinterface (“GUI”) of the integration gateway 12 may be used to name anddescribe the services and their respective characteristics. For example,the Identity tab may be used to access the Log, Process, Persistence,Acknowledgement and Transaction settings described below.

Log

The integration gateway 12 may provide a logging facility to trace therun time of services. These logging facilities may log information atvarious levels, such as the Engine, Service & Message levels. For eachservice, the log level may be set independently according to informationrequirements.

The following types of messages may be made available in the Log files:All (all messages); Debug (messages generated during debugging); Info(information messages, excluding Debug messages); Warning (all warningmessages excluding debug and information messages); and Error (onlyerror messages).

Process

The process configuration on the integration gateway 12 may allow theruntime of each service to be independently controlled. Using a Priorityfield, the priority for each service may be defined. This prioritysetting may help in identifying those service threads that shouldexecute prior to other configured service threads. The default priorityfor each service may be set to five (i.e., the “normal priority”). Onemay be set to the highest priority, and ten to the lowest priority. Theservice pause time may also be defined via this process configuration.

Persistence

Persistence configuration may enable the definition of the Request andResponse Event names for the service. These names, in turn, maydetermine the location of the respective message destinations on the JMSQueue.

The Response event may be configured for a number of services, such as:Database Interface; DotNet Client; DotNet Interceptor; DatabaseInterceptor; S2S Message Client; and/or S2S Voucher End Of Day ReportService.

Acknowledgment Modes

An acknowledgment mode may also be configured to determine the way aservice handles the exchange of acknowledgment information whenreceiving messages from the Queue associated with the integrationgateway 12. In one embodiment, the services may be configured to haveany of four possible acknowledgment modes:

Auto-Acknowledge: In Auto-Acknowledge mode, the client runtime sends aClient acknowledgment instantly for each message it delivers to themessage consumer. The client runtime may then block, waiting for areturn Broker acknowledgment confirming that the Broker has received theClient acknowledgment. This acknowledgment “handshake” between theClient and the Broker may be handled automatically by the Clientruntime.

Client-Acknowledge: In Client-Acknowledge mode, the Client applicationmust explicitly acknowledge the receipt of all messages. This enablesthe deferment of acknowledgment until after the Client application hasfinished processing the message, ensuring that the Broker will notdelete it from persistent storage before processing is complete.

Dups-OK-Acknowledge: In Dups-OK-Acknowledge mode, the sessionautomatically sends a Client acknowledgment each time it has received afixed number of messages, or when a fixed time interval has elapsedsince the last acknowledgment was sent. (This fixed batch size andtimeout interval may be set to 10 messages and 7 seconds, respectively,but may also be configured differently. In one embodiment, however, theclient may not itself configure the batch size or timeout interval.)Unlike in the first two acknowledgment modes described above, the Brokermay not acknowledge receipt of the Client acknowledgment, and thesession thread does not block awaiting such return acknowledgment fromthe Broker. Thus, there may be no way to confirm that the Clientacknowledgment has been received, and, if that acknowledgment has beenlost in transmission, the Broker may redeliver the same message morethan once.

No-Acknowledge: In No-Acknowledge mode, the Client application does notacknowledge receipt of messages nor does the Broker expect any suchacknowledgment. In this mode, there may be no guarantee that any messagesent by the Broker has been successfully received. This mode thussacrifices reliability for maximum message traffic throughput.

Transactions

By enabling transactions, an entire series of incoming and outgoingmessages may be grouped together, such that they may be treated as anatomic unit. The message Broker (e.g., the integration gateway 12) maythen track the state of the transaction's individual messages, but maybe configured to not complete their delivery until the transaction as awhole is committed. In the event of a failure, the transaction may berolled back, canceling all of the associated messages and restarting theentire series from the beginning.

A transacted session may be defined to have exactly one opentransaction, encompassing all messages sent or received since thesession was created or the previous transaction completed. Committing orrolling back a transaction ends that transaction and automaticallybegins another.

Message Settings on GUI

In one embodiment, the Message settings associated with the integrationgateway 12 may allow the configuration of Data transformationalparameters.

Message Configurations

In one embodiment, the Message Processor Plug-ins for Request andResponse messages may be configured. Other message settings may also beconfigured, such as: message type (e.g., string, xml, etc.). Messagesmay also be prioritized according to a particular ‘type’ field of themessage. This prioritization may help in filtering the messages thatshould be processed before other messages. Message scheduling may alsobe used to define the time for processing a given message. For moreinformation on possible configurations that may be made using the userinterface of the integration gateway 12, the User Guide for the BallyIntegration Gateway (p. 38 et seq.) may be consulted. This User Guideprovides some exemplary user interface examples and examples regardinghow one example integration gateway may be implemented.

The above description of illustrated embodiments, including what isdescribed in the Abstract, is not intended to be exhaustive or to limitthe embodiments to the precise forms disclosed. Although specificembodiments of and examples are described herein for illustrativepurposes, various equivalent modifications can be made without departingfrom the spirit and scope of the disclosure, as will be recognized bythose skilled in the relevant art. The various embodiments describedabove can be combined to provide further embodiments. To the extent thatthey are not inconsistent with the specific teachings and definitionsherein U.S. patent publication No. 2008/0162729A1; U.S. patentpublication No. 2007/0082737A1; U.S. patent publication No.2007/0006329A1; U.S. patent publication No. 2007/0054740A1; U.S. patentpublication No. 2007/01111791; U.S. provisional patent application Ser.No. 60/865,345, filed Nov. 10, 2006, entitled “COMPUTERIZED GAMEMANAGEMENT SYSTEM AND METHOD”; U.S. provisional patent application Ser.No. 60/865,575, filed Nov. 13, 2006, entitled “COMPUTERIZED GAMEMANAGEMENT SYSTEM AND METHOD”; U.S. provisional patent application Ser.No. 60/865,332, filed Nov. 10, 2006, entitled “DOWNLOAD ANDCONFIGURATION SERVER-BASED SYSTEM AND METHOD”; U.S. provisional patentapplication Ser. No. 60/865,550, filed Nov. 13, 2006, entitled “DOWNLOADAND CONFIGURATION SERVER-BASED SYSTEM AND METHOD”; U.S. nonprovisionalpatent application Ser. No. 11/938,121, filed Nov. 9, 2007, entitled“GAMING SYSTEM DOWNLOAD NETWORK ARCHITECTURE” (Atty. Docket. No.110184.454); U.S. nonprovisional patent application Ser. No. 11/938,228,filed Nov. 9, 2007, entitled “GAMING SYSTEM CONFIGURATION CHANGEREPORTING” (Atty. Docket. No. 110184.45401); U.S. nonprovisional patentapplication Ser. No. 11/938,155, filed Nov. 9, 2007, entitled “REPORTINGFUNCTION IN GAMING SYSTEM ENVIRONMENT” (Atty. Docket. No. 110184.45402);U.S. nonprovisional patent application Ser. No. 11/938,190, filed Nov.9, 2007, entitled “SECURE COMMUNICATIONS IN GAMING SYSTEM” (Atty.Docket. No. 110184.45403); U.S. nonprovisional patent application Ser.No. 11/938,163, filed Nov. 9, 2007, entitled “METHODS AND SYSTEMS FORCONTROLLING ACCESS TO RESOURCES IN A GAMING NETWORK” (Atty. Docket. No.110184.45404); U.S. nonprovisional patent application Ser. No.11/938,150, filed Nov. 9, 2007, entitled “NETWORKED GAMING ENVIRONMENTEMPLOYING DIFFERENT CLASSES OF GAMING MACHINES” (Atty. Docket. No.110184.453); U.S. nonprovisional patent application Ser. No. 11/938,231,filed Nov. 9, 2007, entitled “DOWNLOAD AND CONFIGURATION SERVER-BASEDSYSTEM AND METHOD WITH STRUCTURED DATA” (Atty. Docket. No. 110184.449);U.S. nonprovisional patent application Ser. No. 11/938,225, filed Nov.9, 2007, entitled “PACKAGE MANAGER SERVICE IN GAMING SYSTEM” (Atty.Docket. No. 110184.455); U.S. patent application Ser. No. 11/278,937,filed Apr. 6, 2006, entitled “LOGIC INTERFACE ENGINE SYSTEM AND METHOD”;U.S. Provisional Patent Application Ser. No. 60/676,429, filed Apr. 28,2005, entitled “LOGIC INTERFACE ENGINE SYSTEM AND METHOD”; U.S. patentapplication Ser. No. 11/470,606, filed Sep. 6, 2006 entitled “SYSTEMGAMING”; U.S. Provisional Patent Application Ser. No. 60/714,754, filedSep. 7, 2005, entitled “SYSTEM GAMING APPARATUS AND METHOD”; U.S.Provisional Patent Application No. 60/865,332, filed Nov. 10, 2006,entitled “DOWNLOAD AND CONFIGURATION SERVER-BASED SYSTEM AND METHOD”;and U.S. Provisional Patent Application No. 60/865,396, filed Nov. 10,2006, entitled “DOWNLOAD AND CONFIGURATION CAPABLE GAMING MACHINEOPERATING SYSTEM, GAMING MACHINE, AND METHOD” are incorporated herein byreference, in their entirety. Aspects of the embodiments can bemodified, if necessary, to employ systems, circuits and concepts of thevarious patents, applications and publications to provide yet furtherembodiments.

For instance, the foregoing detailed description has set forth variousembodiments of the devices and/or processes via the use of blockdiagrams, schematics, and examples. Insofar as such block diagrams,schematics, and examples contain one or more functions and/oroperations, it will be understood by those skilled in the art that eachfunction and/or operation within such block diagrams, flowcharts, orexamples can be implemented, individually and/or collectively, by a widerange of hardware, software, firmware, or virtually any combinationthereof. In one embodiment, the present subject matter may beimplemented via Application Specific Integrated Circuits (ASICs).However, those skilled in the art will recognize that the embodimentsdisclosed herein, in whole or in part, can be equivalently implementedin standard integrated circuits, as one or more computer programsrunning on one or more computers (e.g., as one or more programs runningon one or more computer systems), as one or more programs running on oneor more controllers (e.g., microcontrollers) as one or more programsrunning on one or more processors (e.g., microprocessors), as firmware,or as virtually any combination thereof, and that designing thecircuitry and/or writing the code for the software and or firmware wouldbe well within the skill of one of ordinary skill in the art in light ofthis disclosure.

In addition, those skilled in the art will appreciate that themechanisms of taught herein are capable of being distributed as aprogram product in a variety of forms, and that an illustrativeembodiment applies equally regardless of the particular type of signalbearing media used to actually carry out the distribution. Examples ofsignal bearing media include, but are not limited to, the following:recordable type media such as floppy disks, hard disk drives, CD-ROMs,digital tape, and computer memory; and transmission type media such asdigital and analog communication links using TDM or IP basedcommunication links (e.g., packet links).

The various embodiments described above can be combined to providefurther embodiments. To the extent that they are not inconsistent withthe specific teachings and definitions herein, all of the U.S. patents,U.S. patent application publications, U.S. patent applications, foreignpatents, foreign patent applications and non-patent publicationsreferred to in this specification and/or listed in the Application DataSheetare incorporated herein by reference, in their entirety. Aspects ofthe embodiments can be modified, if necessary, to employ systems,circuits and concepts of the various patents, applications andpublications to provide yet further embodiments.

These and other changes can be made to the embodiments in light of theabove-detailed description. In general, in the following claims, theterms used should not be construed to limit the claims to the specificembodiments disclosed in the specification and the claims, but should beconstrued to include all possible embodiments along with the full scopeof equivalents to which such claims are entitled. Accordingly, theclaims are not limited by the disclosure.

1.-29. (canceled)
 30. A networked server system for use in mediatingelectronic message communication among heterogeneous client devices in acasino gaming environment, the networked server system comprising: anintegration gateway server, selectively communicatively coupled by anetwork to one or more client devices, the integration gateway serverprogrammed to execute instructions that permit communicationtherebetween, according to a selected one of a plurality of messagingmodels, wherein, when an asynchronous point-to-point messaging model isactive, the integration gateway server computer queues an electronicmessage from a message producing client device, and delivers the queuedelectronic message to a designated message consuming receiver clientdevice; and when an asynchronous publish/subscribe messaging model isactive, the integration gateway server computer gathers electronicmessages at a topic destination, and distributes the electronic messagesgathered at the topic destination to a plurality of message consumingsubscriber client devices.
 31. The networked server system of claim 30,further comprising the one or more message producing client devices. 32.The networked server system of claim 30, further comprising the one ormore message consuming subscriber client devices.
 33. The networkedserver system of claim 30 wherein the integration gateway serverdistributes the electronic messages to a particular message destinationspecified in a message header.
 34. The networked server system of claim30 wherein the integration gateway server delivers the queued electronicmessage to a particular message destination specified in a messageheader.
 35. The networked server system of claim 30 wherein theintegration gateway server is further programmed to execute instructionsthat: receive platform-specific data from one or more message producingclient devices; store the platform-specific data in a messagedestination; transform the platform-specific data; re-format theplatform-specific data; and deliver the transformed, re-formatted datato a message consuming client device.
 36. The networked server system ofclaim 30, further comprising a transceiver that provides wirelesscommunication.
 37. The networked server system of claim 30 wherein theclient devices are casino gaming machines.
 38. A method of mediatingelectronic messages between heterogeneous client devices in a casinogaming environment by an integration gateway server computer, the methodcomprising: when an asynchronous point-to-point messaging model isactive, queuing an electronic message from a message producing senderclient device; and delivering the electronic message held in the queueto a designated message consuming receiver client device; and when anasynchronous publish/subscribe messaging model is active, gatheringelectronic messages at a topic destination; and distributing theelectronic messages at the topic destination to a plurality of messageconsuming subscriber client devices.
 39. The method of claim 38, furthercomprising mediating electronic messages in accordance with asynchronous request/response messaging model.
 40. The method of claim 38wherein the queuing the electronic message includes holding the messagewhen the receiver client device is inactive.
 41. An integration gatewayserver communicatively coupled to one or more processor-based casinogaming devices, the integration gateway server comprising: a processor;and a non-transitory processor-readable storage medium communicativelycoupled to the processor, the storage medium having instructions storedthereon that cause the processor to: log electronic messages havingdifferent, platform-specific formats; perform one or more datatransformations that re-format the electronic messages to allowcross-platform communication among the casino gaming devices; andimplement communication services using acknowledgement protocols toensure message integrity.
 42. The integration gateway server of claim 41wherein the non-transitory processor-readable storage medium stores adatabase.
 43. The integration gateway server of claim 41 wherein theinstructions further cause the processor to provide local configurationcache services.
 44. The integration gateway server of claim 41 whereinthe communication services are implemented in accordance with a Systemto System (S2S) gaming industry acknowledgement protocol to enablecommunication among heterogeneous casino gaming devices.
 45. Anon-transitory computer-readable medium communicatively coupled to aprocessor, the non-transitory computer-readable medium havingcomputer-executable instructions stored thereon that when executed bythe processor cause the processor to implement an integration gatewaythat: provides a stand-alone user interface for setup and maintenance ofthe casino gaming machines. establishes cross-platform communicationamong heterogeneous casino gaming machines according to synchronous andasynchronous messaging models; performs data transformations tomanipulate and re-format platform-specific message data according to asynchronous messaging model; and performs data transformations tomanipulate and re-format platform specific message data according to anasynchronous messaging model.
 46. The non-transitory computer-readablemedium of claim 45 wherein the messaging models supported by theintegration gateway include one or more of a publish/subscribe messagingmodel, a point-to-point messaging model, and a request-reply messagingmodel.
 47. The non-transitory computer-readable medium of claim 45wherein the heterogeneous casino gaming machines include legacy systemsand newer products based on evolving technologies.
 48. Thenon-transitory computer-readable medium of claim 45 wherein messagingfunctions provided by the integration gateway include one or more ofguaranteed message delivery, fast message delivery, receiptnotification, transaction control, or a data persistence mechanism. 49.The non-transitory computer-readable medium of claim 45 wherein theinstructions stored thereon further include shared functions andinterceptor services.
 50. The non-transitory computer-readable medium ofclaim 48 wherein the messaging functions utilize objects including oneor more of connection factories, connections, sessions, producers,consumers, messages, or destinations.